Method and apparatus for global relief management

ABSTRACT

A system and method includes providing a database having a plurality of damage characterization data and a geographical location associated with each. A first and a second portable communication unit are associated, respectively, with a first subscribing party and a second subscribing party. A sharing privilege list identifies, for the first subscribing party, parties authorized to receive damage assessment data. A damage assessment report is transmitted from the first of the portable communication units to the database. The database is updated based on the damage assessment report. Then, depending on whether or not the second subscribing party is on the sharing privilege list, a data is communicated to the second of the portable communication units reflecting, or based on, the damage assessment report.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of prior U.S. patent application Ser.No. 10/768,114, filed Feb. 2, 2004. The entirety of this aforementionedapplication is incorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention is directed to a system for managing field levelevaluation and relief efforts and, more particularly, to a system forinputting, characterizing, managing and distributing information for theprovision of humanitarian relief over large and remote geographicalareas.

RELATED ART

A primary objective of organizations, agencies and other entitiesproviding humanitarian relief (collectively referenced as “reliefagencies”) is to provide immediate, necessary relief to victims ofhumanitarian crises arising from, for example, natural disasters such asfloods, earthquakes, hurricanes and man-made disasters such as war. Thedestruction in such situations can involve dwellings, agriculturalsystems, health-care systems, sanitation, transportation, water andpower systems. The crises further include the human risks facingdisplaced populations occupying regions themselves having inadequatesupporting infrastructure. Frequently, because of the scale of thedestruction, and the stricken area's requirement for immediate receiptof a range of necessities, several relief agencies respond. The severalagencies may provide concurrent relief assistance, and/or differentagencies may provide different assistance at respective stages of theoverall relief effort. The agencies must have, and be able todistribute, accurate, real-time information describing the situation.

In a typical present relief effort, such as that provided to a populatedarea after experiencing a high-magnitude earthquake, a plurality ofrelief agencies responds. The agencies may be internationalorganizations (IG), government organizations, (GO), and non-governmentorganizations (NGOs). Each agency typically begins its relief effort bysending in a number of its field personnel. The initial mission of thefield personnel is to obtain damage assessment reports for theirrespective agency. The field personnel typically generate the damageassessment reports by traveling to a damage site and writing downunformatted personal observations on the site's geography, a generalsummary of the population and developmental condition of the area priorto the disaster, if that information is available, and an inventory orestimate of the damage. For example, the field person might write in anotebook that a village named X had an estimated pre-damage populationof two thousand, the population occupying approximately five hundredmud-brick homes, and that they had a local power generating station, anda local water supply. The field person would then write anestimate/inventory of the damage. The write-up information wouldinclude, in an unformatted manner, that approximately 100 mud-brickhomes were still standing, about 200 were damaged but had the majorityof their outer walls reasonably intact, and that the remainder weredestroyed. It would further an estimate of injuries, by number and typeof injuries, and the deaths, including the locations and retrievabilityof the bodies. Other information would be, for example, the fieldperson's observation on the local water supply, including the reservoir,or the wells, and the filtering facilities and distribution system, andassessments of the electrical power system, and other systems of thelocal economy.

After writing the information, the field person would typically type areport and e-mail or fax it to the agency. The agency would then, basedon the information, estimate the relief it could provide.

SUMMARY OF THE INVENTION

An example embodiment of the present system and method includesproviding a database having a plurality of damage characterization dataand a geographical location associated with each. A plurality ofportable communication units are provided, each having a display, amanual data entry mechanism, and a geolocation detector for generating ageolocation data based on an externally generated geolocation signal. Afirst of the portable communication units is associated with a firstsubscribing party and a second of the portable communication units isassociated with a second subscribing party. A sharing privilege listidentifies, for the first subscribing party, at least one othersubscribing party authorized to receive damage assessment data from thefirst subscriber. A geolocation data is generated at the first of theportable communication units based on its geolocation. A damageassessment data is input, by the user, into the first of the portablecommunication units. When entry of the damage assessment data iscompleted a damage assessment report is transmitted from the first ofthe portable communication units to the database, the damage assessmentreport including data reflecting a damage assessment data, anidentification data identifying the sender of the damage assessmentreport, and the geolocation data. In response, the database is updatedbased on the damage assessment report. Then, depending on whether or notthe second subscribing party is on the sharing privilege list, a data iscommunicated to the second of the portable communication unitsreflecting, or based on, the damage assessment report.

In a further embodiment, a plurality of subscribing party headquartercommunication units is provided. A first of the subscribing partyheadquarter communication units is associated with the first subscribingparty and a second of the subscribing party headquarter communicationunits with the second subscribing party. Depending on whether or not thesecond subscribing party is on the sharing privilege list, at least onedata reflecting the damage assessment report is communicated to thesecond of the subscribing party headquarter communication units.

These and other objects, features and advantages of the present systemwill become more apparent to, and better understood by, those skilled inthe relevant art from the following more detailed description of thepreferred embodiments, taken with reference to the accompanyingdrawings, in which like features are identified by like referencenumerals.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example high level block diagram of an example embodimentof the described system;

FIG. 2 is an example high level system-level software architecturesupporting the FIG. 1 system;

FIG. 3 is an illustrative diagram showing an example functionalhierarchy of users of, and nodes within a described system such as thatof the FIG. 1 example;

FIG. 4 is an example functional flow chart for a mobile application suchas, for example, a damage assessment report uploading;

FIG. 5 is an example functional flow chart for web application such as,for example, receiving a damage assessment report from a field unit and,in response, conditionally updating the databases and distributing theinformation;

FIG. 6 is an example damage assessment form with user selectableoptions, displayed on a field unit, for the user to input and uploaddamage assessment data;

FIG. 7 is an example situational map all, or part of which, is displayedon the user's field unit; and

FIG. 8 is an example set of symbols for a real-time situational map.

DETAILED DESCRIPTION OF THE INVENTION

Overview

For purposes of this description, the term “relief agency” encompassesall of the phrase's ordinary and customary meanings including, but notlimited to, government, non-government, and international organizationsand other entities that assess damage wrought by natural forces, such ashurricanes, typhoons, earthquakes, and the damages wrought by man-madeforces such as war and insurrection.

The described system is an end-to-end service through which fieldpersonnel inspect and collect information from disaster areas, theinformation is organized as a selectable privilege-based user-accessibledatabase, and the information is distributed among, through default anduser-selectable formats, and between disaster relief agencies, and otherusers through privilege-based access.

An example of the described system includes a central informationdistribution and management center, one or more agency headquartercenters, and a plurality of field units, which are portablecommunication devices carried by or mounted to the vehicles of fieldpersonnel.

A typical system further includes a wide-area communication network suchas, for example, the Internet, and other described networks forcommunication among and between the field units, the central informationmanagement center, and the one or more relief agency headquartercenters.

In the described embodiments, the field units operate within, and havecircuitry for utilizing, a geo-positioning system such as, for example,the Global Positioning System (GPS). Utilization of geo-positioningsystem is preferred because, as will be described, the field unit'sgeo-location is included in the evaluation reports that the unitsdeliver via uplink to the central information management center.

The field units display graphical user interface (GUI) forms to the userfor entry of damage assessment information and for uploading theinformation as a damage assessment report. The forms are typicallystored in the field units, and are typically customized for theparticular relief agency associated with the field person possessing thefield unit. Updating of the forms by downlink from the centralinformation management center is contemplated. The damage assessmentreports include the geolocation of the sending field unit and a data, orother information, identifying the relief agency associated with thesender. The central information management center has distributionprivilege data that typically maintains, for each relief agency, a listof other agencies, if any, to which the sending agency's damageassessment report information may be distributed. The distributionprivilege data may specify the distribution more particularly, such ascertain types of information being distributed to certain otheragencies.

The field units also display real-time maps to the user, a typical maputilizing geographical map data stored in the field unit on whichupdated situation information, received by downlink from the centralinformation management center, is overlaid and displayed.

DETAILED DESCRIPTION

The following description includes numerous example details andspecifics, some of which pertain only to the specific examplespresented, and which are included only to assist in describing thesespecific examples, and thus assist the reader in understanding thefeatures and elements of the described system. It will be evident toones skilled in the art that the described systems and methods can bepracticed without, and with different ones of, these details andspecifics.

This description assumes the reader to have ordinary skill in therelevant arts of wide-area networks (WAN) such as, for example, theInternet, virtual private networks (VPN) employing public channels,local area networks (LAN), commercially available database software andhardware systems, and the interface protocols for users to access same,available satellite telephone systems, cellular telephone systems, andpersonal computers and hand-held computing devices. Details forimplementing the described systems and methods, to the extent suchdetails are knowledge possessed by persons of skill in the above-listedarts, by which such persons after reading this description can selectfrom among, configure and assemble commercial components into thedescribed systems, are omitted.

FIG. 1 shows a high-level functional block diagram of an exampleembodiment of the system. FIG. 2 is an example system-level softwarearchitectural chart for the software supporting, and implemented on, theFIG. 1 system. It will be understood that FIG. 1 is a graphicrepresentation of an example and is arranged according to functionalblocks. The depicted block segmentation and arrangement is selected toassist in the understanding of functions and operational features of thedescribed system. The depicted blocks do not necessarily represent, orlimit, the physical hardware blocks, or subsystems, for implementing asystem in accordance with this description. For example, as will befurther understood from this detailed description, various functionalblocks of the FIG. 1 example diagram may be implemented on a distributedarrangement of, for example, mass storage units and servers. Likewise, asingle interconnected system of mass storage units, servers and userinterface devices may perform the functions represented by a pluralityof FIG. 1 functional blocks. Still further, the particular FIG. 1segmentation of functional blocks, and the labeling of the blocks, isfor purposes of example only, and is not a limitation on the scope ofthe particular architectures, communication and database structures thatmay be used for implementing the described system.

Referring to FIG. 1, the depicted example system includes a networkoperations center 10, which is referenced hereinafter as the GRT networkoperations center 10, its associated GRT data center 12, a plurality ofcustomer field sites 14, and one or more customer headquarter centers16. A field unit communication network 18 provides for uploadingcommunications from the plurality of customer field sites 14 to the GRTdata center 12 and for downloading communications from the GRT datacenter to the plurality of customer field sites 14. The uploadingfunction of the wireless communication network 18 is represented, alongwith an example list of specific uploading communications, as block 20.Likewise, the downloading function, with an example list of downloadoperations, is represented as block 22. A WAN 24 provides forcommunications between the one or more customer headquarter centers 16and the GRT data center 12. The uploading function of the wide areanetwork 24 is represented, together with an example list of specificuploading communications, as block 26. Similarly, the downloadingfunction of the wide area network with an example list of downloadoperations, is represented as block 28.

With continuing reference to FIG. 1, an example customer field site 14is a portable computing device, preferably ruggedized, such as, forexample, a Panasonic Toughbook™, a Howard Portall Workbook™, or any ofthe equivalents available from various commercial vendors. The customerfield site 14 includes a wireless communication feature, of a typedependent on the implementation of the field unit communication network18 in which the unit 14 is operating. Examples off-the-shelf wirelesscommunication devices are an INMARSAT GAN and an INMARSAT Mini-M, whichare readily attached to commercially available portable computingdevices, such as the Panasonic Toughbook™ and other off-the-shelfexamples of the field site 14 identified herein. The customer field site14 further includes a GPS receiver, or an interface to an external GPSreceiver. An example GPS receiver, which connects to the PanasonicToughbook™ and to equivalent laptop computers, is the Trip-Nav™ model TN200 GPS receiver with Universal Serial Bus (USB) connectivity.

Another example implementation of a field unit 14 is a hand-heldcomputing device such as, for example, a Dell™ Axim™ X5 or X3i,preferably ruggedized with a commercially available environment casing,or “skin”, or an equivalent hand-held such as the Symbol Technologies™model SPT-1800™ or model PPT-2800™, the hand-held computing device,having a GPS receiver such as, for example, a LinksPoint™ GlobalPoint™GPS, or a Pharos™ model PFD22™ GPS receiver, and having, for example, anINMARSAT Mini-M Satellite Phone. These particular make/model ofruggedized laptops and ruggedized handheld computing devices, and theirrespective GPS receivers, are only for purposes of example. Persons ofskill in the relevant arts can, upon reading the present description,readily identify equivalent kinds and models of off-the-shelf devicesavailable from various commercial vendors.

Referring again to FIG. 1, an example implementation of the GRT networkoperations center 10 and its associated GRT data center 12 is the datecenter 12 including one or more commercially available applicationservers 30, a GRT database 32, a web server 34, and an optional firewall36, and the GRT network operations center 10 including a plurality ofuser terminals 38. It should be understood that the GRT networkoperations center 10, the GRT data center 12 and the customerheadquarter centers 16, are functional blocks, and each is notnecessarily a single brick-and-mortar facility. Further, the GRT networkoperations center 10 and the GRT data center 12 are functional blocks,and are not necessarily implemented on hardware systems separate fromone another. Accordingly, the terminals 38 may be co-located with oneanother and with the computer hardware of the GRT data center 12, or maybe distributed over a wide geographic area.

The described components of the GRT network operations center 10 and theGRT database 12, to the extent they are implemented on, or reside inseparate hardware units are connected to one another using, for example,a LAN. The LAN connection, though, is only an example because, as statedabove, one or more of the functions of the GRT network operations center10 and the GRT database 12 can be implemented on distributed hardwaresystems. For example, the GRT database 32 may be a distributed clusterof server-controlled mass storage devices, interconnected by, forexample a virtual private network (VPN) carried over the Internet.Construction, operation and maintenance of distributed cluster databasesis known to persons of ordinary skill in the arts pertaining to thisdescribed system.

An example implementation of the FIG. 1 application server 30 of the GRTnetwork center 10 is a Dell PowerEdge™ server or a Sun SunFire™ server,running under a standard commercially available operating system. Anexample implementation of the database 32 is a Dell PowerVault™ StorageUnit. The identified examples of makes and models of the server 30 andthe database 32 are only for purposes of illustration. Many alternativecommercially available implementations can be chosen from, and theselection from these is a design choice based on conventional selectioncriteria known to persons of ordinary skill in the computer arts.Examples of such selection criteria, which are known, include, forexample, the number of users, size of the database, desired access time,and desired security.

With continuing reference to FIG. 1, the GRT terminals 38 may be, forexample, conventional personal computers or may be what is termed in thepertinent arts as an “ultra-thin client” having only a data input/outputdevice and a visual display device.

With continuing reference to FIG. 1, various implementations of thefield unit communication network 18 are contemplated. A typicalpreferred embodiment is a satellite phone system such as, for example,INMARSAT, because satellite phones provide excellent coverage, to eventhe most remote areas, and do not require a local communicationsinfrastructure. Another contemplated embodiment is a cellular-typenetwork, at least for the portion of the communication network 18 towhich the field unit 14 interfaces. With respect to bandwidthrequirements, it will be understood from the further detaileddescription of the present methods and their example operations that thebandwidth requirements of the field unit communication network 18, atleast for the preferred embodiments, are not particularly high. Reasonsfor the typical bandwidth requirements being not high include theanticipated size of the disaster evaluation files, termed ASSESSMENTfiles and the transmitted DAMAGE ASSESSMENT REPORTS containing same,that will be uploaded by the field units 14, and the anticipated refreshor new report rate, and data quantity per refresh or new report, of thegeographical information, termed AREA SITUATION GIS reports, that willbe communicated from the GRT network operations center 10 to the fieldunits 14.

With continuing reference to FIG. 1, WAN 24, connecting the GRT networkoperations center 10 and its associated GRT data center 12 to the one ormore customer headquarter centers 16 may be implemented on the Internet,or on a combination of the Internet and point-to-point T1 lines, the T1lines being leased from commercial communications entities as known inthe art.

FIG. 2 shows an example system level chart for the software supportingand implemented on the FIG. 1 example system. Dotted line boxes on FIG.2 that have number labels corresponding to the number labels offunctional blocks of FIG. 1 are the software blocks corresponding tothat functional block Referring to FIG. 2, the block labeled “Backend,”with reference numbers 10 and 12, represents the software architecturefor the GRT network management center 10 and the GRT database 12.

With continuing reference to FIG. 2, within the Backend block is the webserver block 40, which is the software associated with the FIG. 1 webserver 34. The web server block 40 processes DAMAGE ASSESSMENT REPORTSand other data uploads and requests from the field units 14, as well asaccess and other requests from the client headquarter centers 16.Example commercial software for implementing these web server 40functions includes the Java Virtual Machine Servlet engine. The othersoftware blocks in the Backend are the GIS Application block 42, the GRTApplication block 44 and Relational Database Management System 46. TheGIS Application block 42 creates, distributes and administers, under thecontrol of the GRT Application block 44, GIS services described herein,and the associated integration of data from the field units 14, the GRTdatabase 32, and outside databases. Example commercial software forimplementing the GIS Application block 42 includes ArcMS˜ and ArcSDE™from ArcSoft™ Corporation, and equivalent software products from othersuppliers such as, for example, ESRI Corp. and Autodesk Corp. TheRelational Database Management System block 46 performs the data storageand management functions described herein, and example implementationsinclude the Microsoft SQL Server product. The GRT Application block 44preferably resides on the FIG. 1 application server 30, and performs thedescribed GRT GIS map and associated data services, including updatingthe GRT GIS maps in response to DAMAGE ASSESSMENT REPORTS, maintainingdifferent GRT GIS maps for different relief agencies, overseeing thetransmission of described reports and alerts to the field units 14, andto relief agencies, and others, associated with the customer headquartercenters 16. Upon reading the present disclosure, persons of ordinaryskill in the pertinent arts listed above can readily write the GRTApplication block software, using commercially available softwarelanguages and development tools.

With continuing reference to FIG. 2, the dotted-line block labeled“Clientside(Field),” having the reference number 14, is a genericrepresentation of the software resident on the field units 14. The FIG.2 Clientside(Field) block includes the Field GRT Application block 48and the Field Database block 50. The Field GRT Application block 48 istypically a subset, at least in part, of the GRT Application block 44 ofthe Backend block The functions of the Field GRT Application block 48,which are more fully described in reference to FIGS. 4-6, include loginoperations, overlaying GIS data with stored local maps, and the uploadand download operations for connecting to, and receiving situationaldata and alerts from the network operations center 10 and other FIG. 1blocks corresponding to the FIG. Backend block containing softwareblocks 40, 42, 44, and 46: The functions of the Field Database blockinclude storing local geographical maps and damage assessment forms.

Referring again to FIG. 2, the dotted line block labeled“Clientside(HQ)” with the reference numeral 16, includes the Viewersoftware application block 52 and the Client Headquarter GRT Applicationblock 54. The function of the Viewer block 52 is for the client, such ashome office personnel of a relief agency, to be able to view thesituational maps downloaded to the agency's field units 14, and theDAMAGE ASSESSMENT REPORTS received from its field units 14. The block 54is shown as a dotted line because typical embodiments contemplate nosignificant application software required at the client headquartercenters 16. Instead, the preferred embodiment contemplates the ClientHeadquarter GRT Application block 54 as an application within the GRTApplication block 44 of the FIG. 2 Backend. Accordingly, the Viewerapplication block 52 can be implemented as, for example, a MicrosoftExplorer or equivalent web browser. It can therefore be seen that theclient headquarter centers 16 are not limited to brick and mortarfacilities. On the contrary, a relief agency can provide certain of itspersonnel with, for example, laptop computers, and agency proprietaryadministrative privilege codes allowing the person to connect, from anylocation having Internet access, and from that location be a clientheadquarter center 16. Software features for the Backend Web Serverapplication block 40, and the GRT Application block 44 implementing sucha “mobile” client headquarter center 16 can be easily written by personsskilled in the listed pertinent arts.

FIG. 3 shows the general privilege hierarchy implemented by the FIG. 1system and FIG. 2 example software architecture. Table I below presentsan example of a further detailed privilege/role definition for the FIG.1 system and FIG. 2 example software architecture. TABLE I USER'SUSER/FIG. 1 BLOCK PRIVILEGES ASSIGNED ROLE GRT - Network Add, Edit,Delete, GRT Administrator Operations Center 10 Approve (upon clientrecommendation), View All Client HQ and Field Data GRT - Network Setsand administers GRT Systems Operations Center 10 privileges for allclients 16 Administrator GRT - Network Views all Client HQ 16 and GRTService Operations Center 10 Field Unit 14 Data Analyst CLIENT HQ -Client Add, Edit, Delete, Client HQ HQ 16 Approve and View OwnAdministrator Client HQ 16 Data and View Own Field Unit 14 Data. CLIENTHQ - Client View Own Client HQ 16 Client HQ Analyst HQ 16 Data and ViewOwn Field Unit 14 Data. FIELD HQ - Client Add, Edit, Delete, FieldAdministrator HQ 16 Approve and View Own Client Field HQ 16 Data andView Own Field Unit 14 Data. FIELD HQ - Client View Own Client FieldField Analyst HQ 16 HQ 16 Data and View Own Field Unit 14 Data. FIELDWORKER - Add, Edit, Delete, Upload Field Worker Field Unit 14 Ownreports, View own HQ 16 data view own field data Others, including Viewauthorized data open Public or other public to public or specific other

A method, and examples of its included operations, as performed on asystem in accordance with the above-described example system 1, will bedescribed Referring to FIGS. 1 and 2, the described operations may beperformed at the field site 14, by operations of its field database 50and field GRT Application software block 48. The references to the FIG.1 depicted example system are not a limitation on the method or itsoperations. Instead, such references enable a better understanding ofthe method, by mapping its example operations onto a system having adescribed architecture. In other words, novel features and aspects ofthe described method are independent of the example system on which theoperation is described.

FIG. 4 is an example block diagram depiction of what is termed herein asa “mobile application”, labeled generally as 100 which, unless otherwisestated, is a mobile user, using for example the customer field site 14of FIG. 1, collection and uploading of disaster descriptive information.As described, the disaster descriptive information typically quantifies,describes, and/or categorizes the kinds and quantities of disasters anddisaster-related damage. FIG. 5 is an example block diagram depiction ofwhat is termed herein as a “web application”, labeled generally as 200which, unless otherwise stated, is an operation performed at, orincluding, a management center and central database, such as the GRTnetwork operations center 10 and GRT data center 12. As will bedescribed, examples of such web applications 200 are collecting theuploaded disaster descriptive information, which are termed ASSESSMENTfiles in the examples described herein, updating the central database,and the distribution of all, or portions of the disaster descriptiveinformation to other users and databases, such as the clientheadquarters 16, and other customer field sites 14.

Referring to FIG. 4, block 102 represents the start of a mobileapplication 100. An example implementation of block 102 is a userswitching on and/or logging into his or her customer field site 14. Forblock 102 the term “logging in” and “log on” may include interactionswith, and gaining access to only the customer field site 14, withoutestablishing a “session”, as that term is known in the pertinent arts,with the GRT management center 10. Such log on or logging in operations,including designation and entry of security passwords, are well known inthe pertinent arts and, therefore, further description is not necessary.Upon completion of the block 102 start operation, the process goes toblock 104 to collect and generate GEODATA, which is geopositioncoordinate data such as, for example, that available from GPS.

After, or concurrent with collecting geoposition coordinate data atblock 104, the process goes to block 106 for selection of one or moretypes of damage assessment and to start entering observed damage andsituational information. FIG. 6 shows an example damage assessmentoptions form 400 presented to the user at block 104, for use m selectingand starting a site assessment. Referring to FIG. 6, the user ispresented with a plurality of assessment forms which, for this exampleare: LOCATION 402, LOCATION/LEADERSHIP 404, POPULATION 406, SHELTER 408,SANITATION/SAFE WATER 410, HEALTH/NUTRITION 412, INFRASTRUCTURE 414, andECONOMY 416. The FIG. 6 list is only for purposes of example. The numberof specific types of damage assessment forms is a design choice. Theform that is visible on FIG. 6 is the SHELTER damage assessment form408.

The FIG. 6 depicted example SHELTER damage assessment form 408 presentsthe user with a damage level assessment guide 420 showing four levels ofdamage, labeled 420A, 420B, 420C and 420D, respectively named as“None/Minor,” “Moderate,” “Severe” 420C and “Destroyed,” with anillustrative example of each as a guideline. The FIG. 6 example form 400assigns numerical values of “1”, “2”, “3”, and “4” to the four levels ofdamage, to better enable user entry of these damage assessment valuesinto the form 408, as will be described. It will be understood that theparticular damage level assessment guide 420 shown by FIG. 6 is only anexample. Other names, numerical values and illustrative examples ofdamage could be used. Further, it is contemplated that the softwaredisplaying the SHELTER damage assessment form 408 could includeadditional guidelines for the damage level assessment guide 420. Forexample, a “right click,” other user operated options selector, when amouse cursor, or other GUI user-movable pointer, is positioned on aspecific example damage type, such as 420B “Moderate,” could display anoptions list allowing the user to select, for example, a longernarrative description. Such “right click” and other types ofuser-friendly means for accessing user interface options associated withan icon or GUI field are well known in the above-listed pertinent arts.

The FIG. 6 example SHELTER damage assessment form 408 includes thefollowing graphical user interface (GUI) data enter fields: TOTAL #RESIDENCES field 422, ESTIMATED PERCENTAGE DAMAGED UNITS fields 424A,424B, 424C and 424D, for damage levels “1”, “2”, “3” and “4”,respectively, PREDOMINATE BUILDING MATERIALS fields 426A through 426E,and corresponding BUILDING MATERIAL PERCENTAGE fields 428A through 428E.The FIG. 4 example form 400 also includes ESTIMATED NUMBER DAMAGED UNITSfields 430A through 430D as an alternative to the ESTIMATED PERCENTAGEDAMAGED UNITS fields 424A, 424B, 424C and 424D.

Each of the remaining forms 402, 404, 406, 410, 412, 414, and 416 have asimilar arrangement to the visible example SHELTER damage assessmentform 408, namely guidelines, buttons, and GUI data entry fields forguiding the user, and effectuating his or her entry of informationassessing damage of the type that the form is labeled to collect. Theforms 402-416 may also include pull-down lists, sub-forms, andassistance files stored in the displaying device, e.g., the field site14. Such pull-downs and assistance files are known in the above-listedpertinent arts.

Referring to FIG. 4, at block 106 the user selects an assessment form,such as one of the FIG. 6 damage assessment forms 402-416 by, forexample, clicking on the visible top tab and then proceeds to block 108for collecting damage assessment data. Using the FIG. 6 visible SHELTERdamage assessment form 408 as an example, the user proceeds to enterdata into the form Examples are the number of residences at the site ofthe damage, which the user would enter into the TOTAL # RESIDENCES field422 and, for each of the damage levels “1”, “2”, “3”, and “4”, thecorresponding number of the residential, which the user would enter intofields 430A through 430D.

When the user has completed entry of the data for the form 408 he or shereviews the entries. If they are satisfactory, the user clicks on the“OK” button 432, which closes the “window,” as the visual display of aform such as 408 is known in the pertinent arts, and stores the enteredvalues. If the entries are not satisfactory, the user either edits theentries or clicks on the CANCEL button 434. The user then either clickson one of the remaining forms 402, 404, 406, 410, 412, 414 and 416,thereby continuing with block 108, or clicks on the SEND tab 430 totransmit or upload the ASSESSMENT file. If the user clicks on the SENDtab 430 the process goes to block 110, where it saves the ASSESSMENTfile and transmits a DAMAGE ASSESSMENT report, having the ASSESSMENTfile, to the management center. For this example, the management centeris the GRT network operations center 10. The ASSESSMENT file includesthe GEODATE generated at block 104, and a USERID data. The USERID datamay be prestored in the user's device, such as the field site 14, or maybe entered by the user at the start block 102. Depending on the specificimplementation, the ASSESSMENT file may also include AGENCYID data,which represents the relief agency that the user is associated with. Aswill be understood from the further detailed description, in referenceto FIG. 5, of an example web application, the GRT network operationscenter 10 may use the AGENCYID for routing, and for determining thedistribution of the ASSESSMENT file. Similar to the USERID, the AGENCYIDmay be prestored in the user's device, e.g., the field site 14, orentered by the user during the execution of block 102.

The particular operations for carrying out the transmitting, oruploading, of the ASSESSMENT file depend on the particularimplementation of the system. For example, referring to FIG. 1, if thefield unit communication network 18 is a satellite phone system, such asINMARSAT, uploading the ASSESSMENT file would typically include thedialing protocol, and formatting the ASSESSMENT file as required by thesatellite phone service provided The uploading may be implemented as ane-mail operation, as satellite phone-based e-mail transmission is knownin the art. Software for the uploading operations is typically supplied,off-the-shelf, by the satellite phone service provider.

Referring to FIG. 4, the depicted blocks are only for purposes ofexample. Many variations and other design choices can be implemented bypersons skilled in the above-listed pertinent arts upon reading thisdisclosure. For example block 110 could be executed, i.e., an ASSESSMENTfile transmitted to the GRT network operations center 10 each time theuser clicks the OK button 432. Another variation or option is that thedamage assessment options form 400, or one or more of the specificdamage assessment forms such as 402 through 416, could include apull-down or other GUI data entry field for entry of a priority code orattribute. In other words, a priority code or attribute could beincluded whereby the user assigns, by requirement or option, a prioritycode or attribute to an ASSESSMENT. As will be understood in view of thedescription in reference to FIG. 5, such a priority or kind attributecould be used for determining the scope of dissemination of the DAMAGEASSESSMENT.

Another variation or option for the FIG. 4 mobile application is thatimmediately after block 104 generates the GEODATA specifying thelocation of the field unit 14, a “here I am” type of notice could beuploaded to the GRT network operations center 12, prior to proceeding tothe assessment block 106. Such a field unit location notice could, inturn, be immediately forwarded to the client headquarters 16 of thespecific relief agency associated with the sending field unit 14. Thiswill be addressed further in the description referencing FIG. 5 ofmethods and operations carried by the GRT network communications center10 and GRT data center 12 upon receipt of an ASSESSMENT file.

A still further variation, is that immediately after the field unit 14sends a “here I am” type of notice, the GRT network operations center 10would immediately download information relevant to the user associatedwith the sending field unit 14. As described more fully in reference toFIG. 5, the information would be based in part on the particular user,as reflected by the USERID, and the relief agency that the user isassociated with.

The FIG. 4 method, as described, uses forms stored in the field unit 14.As depicted by FIG. 4, the only communication between the field unit 14and the GRT network operations center 10 is the uploading of the DAMAGEASSESSMENT REPORT at block 110. One benefit of this FIG. 4implementation of uploading damage information is that it typicallyminimizes bandwidth and channel integrity requirement for the field unitcommunication network 18. An alternative is to structure thecommunication, in whole or in pan, between the field units 14 and theGRT network operations center 10 clients in a web-type system, with lessthan the entire set of assessment forms actually stored in the fieldunit 14. User entry of damage assessments, and uploading of theinformation from each, could be performed in a web-browser mode, or in aremote dial-in session mode. Bother of these remote user access methodsare known in the above-listed pertinent arts. This may be preferred forcertain implementations.

Referring to FIG. 6, an example operation of a block flow for a webapplication 200 utilizing, for this example, a system in accordance withFIG. 1 will be described. Referring to FIGS. 1 and 2, the describedoperations maybe performed at the GRT network operations center 10 andthe GRT data center 12, by operations of the Web Server application 40,the GIS Application 42, the GRT Application 44 and the RelationalDatabase Management System 46. Referring to FIG. 6, block 202 representsa start web application that may, for example, be a GRT networkoperations center 10 receiving a DAMAGE ASSESSMENT REPORT uploaded atblock 110 of the FIG. 4 example mobile application 100. The webapplication 200 then proceeds to block 204, where the DAMAGE ASSESSMENTREPORT is reviewed. The specific operations performed by block 204 are,to a substantial extent, either a design choice or are based onrequirements specific to the relief agency associated with the fieldunit 14 that sent the DAMAGE ASSESSMENT REPORT. The FIG. 6 webapplication 200 contemplates the review operations at block 204 being acombination of automatic review, for template-type qualificationcriteria such as, for example, required GUI fields being filled out, andreview requiring, or allowing for, human judgment. The block 204 reviewdecision branch is represented as block 206. As shown, if the DAMAGEASSESSMENT REPORT fails the criteria applied at block 204 the processgoes to block 208 and ends.

If the DAMAGE ASSESSMENT REPORT meets the criteria applied at block 204,and there is no manual override, the process goes to block 210, whichdecides whether the data included in the DAMAGE ASSESSMENT REPORT isshared with agencies other than the agency associated with the fieldunit 14 that sent the report. The sharing decision or rules are notnecessarily global with respect to the entire DAMAGE ASSESSMENT REPORTand, instead, sharing may be different with different parts of thereport data. The sharing rules are set by the relief agencies and may,for example, be updated by a web session invoked at an agency'srespective client headquarter center 16. It is further contemplated thatfinal implementation of a change to the inter-agency sharing rules mayrequire transmission of the proposed change from the GRT networkoperations center 10 to the proposed receiving agency and receipt ofauthorization from that agency.

If block 210 determines the information from the DAMAGE ASSESSMENTREPORT to be not sharable, the process goes to block 212. Blocks 222-226will be discussed further below. If block 210 determines that theinformation from the DAMAGE ASSESSMENT REPORT is sharable the processgoes to block 214 to incorporate data, or certain fields or portions ofthe data into the various GIS databases, or user-apparent GIS databases,stored by the GRT date center 12. Referring to FIG. 2 the specificarrangement by which the Backend Relational Database Management System46 maintains, or can provide, a different GIS database, or apparent GISdatabase, for each of relief agency, e.g., each different clientheadquarters 16, is a design choice. The term “apparent GIS database” isused because the Backend Relational Database Management System 46 may beconfigured to maintain a plurality of records, each record having fieldsof, for example, location, date, damage type(s), damage quantity(ies),reporting agency(ies), authorized sharing agencies, a data qualityindicator, and other situational facts such as, for example, ongoingarmed conflict. To generate an updated map, such as the below-describedSITUATIONAL MAP (G, A), where G is an index for geographical area and Ais an index for the agency receiving the map, the Backend blocks 42, 44and 46 may retrieve data for overlays representing all facts from thedatabase that are within or associated with the G geographical area andare (a) authorized for the A agency to see and (b) preselected by the Aagency for seeing. It will be understood that the “G” and “A” indicesare only for purposes of describing a function of blocks 214, 216 and218, in that the actual implementation of Backend blocks 42,44 and 46may have no such index.

Referring again to FIG. 5, block 214 incorporates the DAMAGE ASSESSMENTREPORT into the GRT database center 12, under control of the BackendRelational Database Management System 46 and then proceeds to block 216to generate a new SITUATIONAL MAP (G, A), and to block 218 to transmitan UPDATE REPORT (G, A), using the same G and A indices to represent thegeographical area(s) and agency(ies), respectively, to which the UPDATEREPORT will be sent.

The process by which the field sites 14 receive an UPDATE REPORT islargely a design choice. For example, referring to FIG. 4, each time auser logs in at block 102 and the site 14 transmits a “here I am”notice, the site 14 may receive all UPDATE REPORTS that the user isauthorized to receive. Depending on the implementation, the user may begiven a choice to see UPDATE REPORTS that have no information with therespect to the location of field site 14. A variation for the reportblock 218 of FIG. 5 is that the user would have to send a “check forupdates” request, instead of automatically receiving the update. Stillanother variation is to send a “check for updates notice” to the personslisted as authorized users of agency's' field sites 14 by, for example,wireless e-mail. These and other implementations for the block 218transmission of the UPDATE REPORTS to field sites 14 are readilyperformed by persons skilled in the above-listed pertinent arts.

Block 218 also sends UPDATE REPORTS to the relief agency(ies) at, forexample, their respective client headquarter sites 16. This may be doneby, for example, e-mail, with the e-mail having the UPDATE REPORTattached, or by an e-mail notice for the agency(ies) to log into theirrespective GIS databases and check for updates using, for example, theFIG. 2 viewer/web browser block 52. The process then goes to block 220and ends.

Referring to FIG. 5, if block 210 determined that the DAMAGE ASSESSMENTREPORT was not sharable, blocks 212 followed by 222 through 226 areexecuted much the same as blocks 214 through 220, the only differencebeing that only one relief agency and one relief agency's field sites 14receive the UPDATE REPORT.

FIG. 7 is an example display, either on the video display of thecustomer headquarters 16 or the video display of the field sites 14, aswould be seen after receiving an UPDATE REPORT. The FIG. 7 example usescall-outs that describe, with words, situations at a plurality ofgeographical locations. FIG. 8 is an example of symbols for use inoverlay maps displayed on the video display of the customer headquarters16 or the video display of the field sites 14, either separate from inconjunction with call-outs as shown by FIG. 7.

While the present system has been disclosed with reference to certainpreferred embodiments, these should not be considered limitations. Oneskilled in the art will readily recognize that variations of theseembodiments are possible, each falling within the scope of the system,and as set forth in the claims below.

1-6. (canceled)
 7. A device for capturing and communicating fieldassessments, the device comprising: a data store that stores informationincluding: a base map corresponding to a geographical area; anduser-selectable field assessment forms; a user interface that displaysat least a portion of the base map and captures field assessments usinga selected one of the user-selectable field assessment forms in the datastore, each field assessment associated with a location within thegeographical area; and an electronic communication interface fortransmitting captured field assessments to a server.
 8. The device ofclaim 7, further comprising a geolocator interface operable to receivegeolocation information for associating field assessments with locationswithin the geographical area.
 9. The device of claim 7, wherein theelectronic communication interface is operable to transmit and receivecommunications via a satellite.
 10. The device of claim 7, wherein theelectronic communication interface is operable to receive one or moreuser-selectable field assessment forms.
 11. The device of claim 7,wherein the electronic communication interface receives updatedsituational information, and the user interface is operable to displayat least a portion of the updated situational information overlaid on atleast a portion of the base map.
 12. A server for use in a global reliefmanagement system, the server comprising: a field assessment devicecommunication interface to facilitate receiving field assessments fromfield assessment devices and to facilitate transmitting updateinformation to field assessment devices; geographic information systemdata; field assessment data, the geographic information system data andthe field assessment data updated using received field assessments;access control information; and a report generation interface tofacilitate access to the geographic information system data and thefield assessment data, the report generation interface controllingaccess to the geographic information system data and the fieldassessment data using the access control information.
 13. The server ofclaim 12, wherein the field assessment device communication interfaceuses a satellite-based communication link.
 14. The server of claim 12,wherein the report generation interface is web-based.
 15. The server ofclaim 12, wherein the geographic information system data and the fieldassessment data are stored in a relational database.
 16. The server ofclaim 12, wherein the report generation interface requiresauthentication.
 17. A data security method in a global relief managementsystem, the data security method comprising: receiving a fieldassessment submitted using a field assessment device; maintaining fieldassessment access control information; and controlling dissemination ofat least a portion of the received field assessment based on themaintained field assessment access control information.
 18. The methodof claim 17, wherein the received field assessment is associated with afirst organization, and the maintained field assessment access controlinformation prohibits dissemination of one or more portions of thereceived field assessment to organizations other than the firstorganization.
 19. The method of claim 17, wherein the maintained fieldassessment access control information implements a privilege hierarchy.20. The method of claim 17, wherein the received field assessmentincludes an attribute used in controlling dissemination of at least aportion of the received field assessment.
 21. The method of claim 17,wherein maintaining field assessment access control information includesmaintaining access control information defining information sharingbetween government organizations and non-government organizations.
 22. Amethod for generating organization-specific reports in a global reliefmanagement system, the method comprising: identifying a geographicalarea; identifying a requesting organization; querying a data store forinformation in the identified geographical area that is accessible bythe identified requesting organization; retrieving informationsatisfying the query; and preparing the retrieved information togenerate a report.
 23. The method of claim 22, wherein retrievinginformation satisfying the query includes retrieving geographicinformation system information, and preparing the retrieved informationto generate a report includes creating a map based on the retrievedgeographic information system information.
 24. The method of claim 22,further comprising transmitting the generated report.
 25. The method ofclaim 22, wherein the generated report is a representation of one ormore field assessment reports.
 26. The method of claim 22, wherein thegenerated report includes update information corresponding to theidentified geographical area and the identified requesting organization.27. A method for updating a field assessment device comprising:determining a geographical location of a field assessment device;transmitting a message indicating the geographical location of the fieldassessment device and identifying a user of the field assessment device;receiving update information in response to the transmitted message, theupdate information corresponding to the identified user and theindicated geographical location.
 28. The method of claim 27, wherein thegeographical location of the field assessment device is determined usinga global positioning system receiver.
 29. The method of claim 27,wherein the update information includes a map overlay.
 30. The method ofclaim 27, wherein the update information includes at least one fieldassessment form.
 31. The method of claim 27, wherein the updateinformation further includes at least one field assessment.